IBIS Macromodel Task Group Meeting date: 26 Jun 2012 Members (asterisk for those attending): Agilent: * Fangyi Rao Radek Biernacki Altera: * David Banas * Julia Liu * Hazlina Ramly Andrew Joy Consulting: Andy Joy Ansys: Samuel Mertens * Dan Dvorscak * Curtis Clark Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: Michael Mirmak LSI Logic: Wenyi Jin Maxim Integrated Products: Mahbubul Bari Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: * Randy Wolff NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: * Eckhard Lenski QLogic Corp. James Zhou Sigrity: Brad Brim Kumar Keshavan Ken Willis SiSoft: * Walter Katz Todd Westerhoff Doug Burns Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad to submit the following BIRDs to the IBIS Open Forum: - ParameterTreeKeyword_BIRD_draft4 - BIRD 117.4 draft6 - BIRD 118.3 draft5 - BIRD 116 as 116.1 (last week's "ISS" to "IBIS-ISS" change) - done - Arpad & Walter to propose an alternative to using "Labels" to control the Dependency Table. - done - Bob to propose a simpler way for addressing the needs of parameter passing under [External Model] and [External Circuit] - not done ------------- New Discussion: BIRD 150 (Dependency Tables): - Walter: (sharing BIRD 150.1 Draft) - There was a request that the string substitution capability be removed. - Arpad: Just to be clear, I only asked to separate it into a different BIRD. - Walter: yes, so it's been removed. Separate BIRD will come later. - New "Usage" Dependency Table. - Instead of Labels within the Table serving as column headings: - Two New Reserved Leaf Names - ParameterNames - ColumnTypes - Had to remove the paragraph describing 5.0 and 5.1 compatibility. - Note that some vendors have used the 5.0 "parser" compatible style. - Editorial changes including changes to examples to reflect new approach. - Everything else has been quite stable for a long time. - Please read it thoroughly so we can discuss it next time. - Arpad: Is this the document that is posted on the ATM website? - Walter: Yes. - David: motion to table this until next time (per Walter's suggestion). - Arpad: second the motion. (no objections) Package Modeling Discussion: - Walter: I sent an email out shortly before the meeting. - It is consistent with Brad Brim's approach - It describes a current modeling requirement in the market. - Arpad: I read it, are your comments related to my presentation? - Walter: yes - Walter: sharing IBIS file format model email (example) - IBIS file has 6 Power Pins and 8 Buffer Pins - Looking at the Silicon - same number of buffer pads - greater number of power pads (4 bump pads per power pin) - Power distribution modeling in low, med, high frequency. - David: - What is the significance of the underscore? - Walter: - underscore - ball (pin) - without underscore pad. - Walter: - Low frequency - perhaps 1 power pin node and one pad node. - High Frequency - 6 pin nodes and 24 power pad nodes. - Med Frequency - 2 pin nodes and 6 power pad nodes. - Could depend on how the EDA tool extracts the model. - Walter: - Similar problems on die. - Multiple buffers - Low frequency - 1 power pad, 1 buffer pad - High frequency - 24 power pads, 8 buffer pads. - May even provide multiple power models and package "slices". - Brad Brim, Sigrity, Cadence, IC and package vendors have a solution. - Model Connection Protocol - standard for one die and package power models. - comment characters in HSPICE provide the syntax a tool can read and use. - subcircuit advertises how it is to be used and connected. - Real world example as SiSoft has done it. - I recommend that we not include the package distribution model in IBIS. - Arpad: Are these model variants supposed to be: - separate models to be selected by a "model selector" type arrangement or - a single model which supports "compression" or "expansion" capabilities like swathing, to cover the various levels of simulation conditions? - Walter: The way we do it you select a subcircuit to use for power - The user makes the choice of which subcircuit to use for given conditions. - Opportunity for IBIS is to utilize MCP. - I don't like many things about the MCP syntax, but it does work. - With MCP you drop models into your netlist. - Michael: Do you foresee this coming from model makers, or made by EDA tools? - Walter: I would expect with Sigrity's tool to press a button and have it generate this model. - EDA tools make their models via extraction, measurement, etc. - put the model in a subcircuit - perhaps generated automatically. - Michael: I'm having a tough time envisioning manual creation of these. - Does the end user care about this? - Walter: Model makers, IC vendors, systems integrators care. - Model makers care about what is exposed. - A consortium of IC vendors came up with this to define how to connect. - Somewhat painful process about a year ago as MCP was discussed. - This example was trying to illustrate some of what came out of that. Move on to Arpad's Presentation on this topic: - Arpad: (sharing his power point presentation) - Summary of where we are now (last week's discussion) - BIRD 116-118 review - Legacy overview - Important point - IBIS does not declare pads on the die. - Current state of BIRD 125 - Introduces Die_Port_Names - [Package Circuit] provides IBIS-ISS description. - David: Do we have that functionality already with Signal Names in the [Pin]? - Arpad: Use Signal Name column for that purpose? - My first reaction is that it might be dangerous, not sure. - David: I would recommend a new column instead of repeating "Die_Port_Name=" - Arpad: Okay, I'm open to syntax suggestions once we get through this. - Michael: Sorry, another syntax question: - Are you saying even the [Pin] keyword could have a new column? - Are you ruling this out? - Arpad: If it's okay I'd like to hold syntax questions for now. - Arpad: (sharing picture of the "famous Figure #12" from the IBIS spec) - This example is famous because we had a lot of discussions on it when trying to implement it with ICM. - How do we declare [Model] power terminal connections to specific pins? - Extend the use of [Pin Mapping] keyword. - Modified Figure #12 explicitly showing power and ground connections. - Arpad: Major issue with legacy IBIS: - Only one way to define the buffer model for a pin. - If a pin is tied to multiple buffers, how do we handle it? - Similar problem arises if multiple signal pins feed one buffer. - Now we also need on die interconnect. - Legacy IBIS one-to-one pin to buffer is useful for some things. - identify which [Model] is used on a net for a PCB layout or IC footprint - can't be abandoned entirely. - Best solution for instantiating [Model]s might follow [External Circuit]: - use a [Model Call] syntax analogous to the existing [Circuit Call]. - Allows multiple [Model]s to be instantiated per pin. - Provides named terminal definitions. - Doesn't rely on the cumbersome [Pin Mapping] syntax. - [Node Declarations] can define nodes on either side of the on-die interconnect model. - No need for one to one legacy scheme. - Michael: That's a nice diagram, very helpful. - Is this different than what a "clean sheet of paper" would produce. - If you started with pins, pads, packages, buffers, would you come up with this? - Arpad: Interesting question. - I started with a "clean sheet" approach and ended up with these legacy keywords. - Their use did not seem to be stretched. - I started with a solution similar to the SPICE X-element syntax. - We could consider that, but it seemed that this syntax provides everything we need with the least amount of change, and everything shown here is covered by BIRDs 116, 125 and 145. - Walter: My email focused only on power distribution on die. - Signaling is an independent problem not addressed in my example email. - I think your scheme might work for a single package model. - In practice it won't work or will be very cumbersome for multiple models. - Arpad: Okay, we're out of time. - Arpad: What should we do about next week's meeting (July 3)? - Will people not be attending? - Michael: I think we should cancel it. - Arpad: Next week's meeting is canceled. ------------- Next meeting: 10 Jul 2012 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives